Границы CCPM

Управление проектами по методу Критической цепи (Critical Chain Project Management, CCPM) является наиболее успешным и широко известным приложением Теории ограничений (ТОС). Первой поразительной особенностью CCPM является управление неопределенностью, а второй – понимание, как влияют показатели производительности на поведение человека и на саму производительность.

Сначала я остановлюсь на управлении неопределенностью, потому что добавление временного буфера проекта в конце проекта – это весьма смелое заявление о том, что мы на самом деле НЕ знаем точную дату завершения проекта. Это более прозрачный буфер, чем буфер ББК, который выглядит как обычное время выполнения заказа, связанное с цепочкой операций. Эта концепция буфера проекта является значительным вкладом в управление «обычной и ожидаемой» неопределенностью.

Знаменитое высказывание Голдратта: «Скажи мне, как ты меня будешь оценивать, и я скажу тебе, как я буду себя вести», было придумано за десять лет до CCPM. Действительно, негативное влияние показателей производительности на поведение людей отчетливо проявляется в цехах, но еще более оно очевидно в проектной среде, где люди являются ключевыми ресурсами. Разрушительное использование многозадачности также связано с показателями производительности, которыми оценивают каждого менеджера проекта изолированно от всех менеджеров других открытых проектов и тем самым вынуждают каждого бороться за «свой» проект.

Хотя CCPM является прорывом и несет огромную ценность, всегда нужно спрашивать: Каковы границы данной методологии? Другими словами, когда использование CCPM выгодно, а когда необходимо внести определенные изменения?

Все сводится к проверке исходных посылок, лежащих в основе методологии, и определению, когда они недействительны.

Просто чтобы проиллюстрировать это, давайте представим программу по поиску лекарства от рака. Можно ли в начале такого исследования определить дату его завершения? Можно ли построить последовательность задач для всего проекта? Мы хотя бы примерно представляем, сколько времени это займет? Есть ли смысл в буфере проекта, если у нас даже нет даты, куда его можно вставить?

Вот мой список главных исходных посылок, лежащих в основе CCPM, которые иногда могут быть неверными в определенных ситуациях:

1. У нас есть достаточно хорошая идея, как выполнить проект от начала до конца.
   • В частности, с самого начала проекта у нас есть хорошая идея, какие функции должны быть разработаны.
   • У нас нет условных точек в проекте (если…, то…, иначе…), которые могли бы кардинально изменить последующие операции или вернуть к более ранней задаче.
2. Завершение проекта раньше или в установленный срок имеет первостепенное значение.
3. Завершение проекта в срок не ставит под угрозу реализацию всех технических функций и бюджет.
4. Контроль за ходом выполнения проекта и его сроками находится в наших руках.
5. Мы планируем постоянно работать над критической цепью. Без этого определение критической цепи как самой длинной цепи, определяющей длительность проекта, бессмысленно.

Что происходит, когда одна или несколько основных исходных посылок недействительны?

Давайте рассмотрим два примера. Предположим, клиент должен принять определенные этапы проекта, и для этого он должен потратить свое время. Тогда две посылки недействительны: четвертая и пятая. Четвертая недействительна, потому что у нас нет средств, чтобы заставить клиента придерживаться нашего графика. Пятая недействительна, так как весь проект находится в ожидании на время проверки клиента. Можно включить эту задачу клиента в план и выделить на нее до половины времени проекта. Но суть в том, что если клиент дает (не дает) сигнал о том, что можно двигаться дальше, как вы сможете соблюдать сроки?

Моя рекомендация для такого случая – разбить весь проект на подпроекты. Команда проекта контролирует ход выполнения до тех пор, пока клиент не получит выходные данные для подтверждения, что фактически является завершением проекта. Как только клиент «дает добро», начинается следующий проект. Даже если при приемке у клиента появляются новые требования, они входят уже в новый проект.

Рассмотрим другой проблемный проект – где срок завершения является обязательным, а отсрочка невозможной. В таком случае в «завершенном» проекте может оказаться намного меньше функций, чем в первоначальном плане, или расходы на его завершение в срок могут резко возрасти. Это означает, что третье предположение теперь является недействительным. Буфер времени не защищает все действительно важные переменные. Планирование такого проекта должно четкое разделять «обязательные» и «желательные» функции. Здесь я вижу возможное решение с буфером для желательных функций дополнительно к буферу проекта, защищающего обязательную дату завершения.

Общее замечание: я считаю CCPM наименее целостным методом в TOC. Он нацелен на решение проблемы, которая является довольно распространенной, но не обязательно ключевой проблемой организации. Меня беспокоит, что это решение для нежелательного явления (НЖЯ), без изучения общей картины. Вы можете улучшить управление проектами в организации, но организация не сможет достичь своей цели.

Хочу закончить историей в тему: недавно я встретил высокопоставленного руководителя огромного международного концерна. Когда я упомянул о хорошей реализации CCPM в израильском подразделении, он прокомментировал: «Да, они досрочно завершили НЕНУЖНЫЙ проект!».

Вот результат, когда TOC применялась только для планирования и выполнение проекта. Почему инструменты ТОС не были использованы, чтобы в начале убедиться, что это ПРАВИЛЬНЫЙ проект с правильным набором функций и спецификаций? Можно ли это сделать в отрыве от стратегии организации?

Источник: блог Эли Шрагенхайма

Критическая цепь. Управление проектами по ТОС

Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.

Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 3 июня 2024.

ПОДРОБНЕЕ

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

Читайте, где удобно

  Telegram

  VKontakte

Эли Шрагенхайм

Eli Schragenheim,
CEO of Elyakim Management Systems (1992) Ltd